1. Field of the Invention
The present invention relates to a data processing apparatus and method for measuring a value of a predetermined property of transactions, an example of such a predetermined property being latency of transactions.
2. Description of the Prior Art
Transactions are used within a data processing system as a mechanism for communicating between master devices and slave devices. As an example, if a master device wishes to read data from, or write data to, a memory, the master device may initiate a transaction to be handled by a memory controller (a slave device) associated with the memory. A transaction will typically comprise an address transfer issued from the master device to the slave device, and one or more data transfers between the master device and the slave device. For a read transaction, these data transfers will pass from the slave device to the master device, whilst for a write transaction these data transfers will pass from the master device to the slave device.
A master device may be coupled directly to a slave device via a dedicated communication path. However, in modern data processing systems, it is more usual for a number of master devices and slave devices to be interconnected via interconnect circuitry. The interconnect circuitry provides a matrix of communication paths via which master devices coupled to the interconnect circuitry can communicate with slave devices coupled to the interconnect circuitry. In such embodiments, rather than there being a single dedicated communication path between a master device and a slave device, communication between a master device and a slave device can be considered to take place via a series of communication paths, where each communication path has initiator circuitry at one end and recipient circuitry at the other end. For example, starting with the master device initiating a transaction, there will be a communication path from that master device to a slave interface of the interconnect circuitry, where the master device can be viewed as the initiator circuitry and the slave interface of the interconnect can be viewed as the recipient circuitry. Similarly, there will be one or more communication paths provided through the interconnect circuitry, with each communication path having a master interface forming initiator circuitry for that communication path and a slave interface forming recipient circuitry for that communication path. It will be appreciated that a slave interface for one communication path may itself operate as a master interface for the next communication path along the route between the master device and the slave device. Finally, there will be a communication path from a master interface of the interconnect circuitry to the recipient slave device itself, and for this communication path the master interface of the interconnect circuitry will form the initiator circuitry and the slave device will form the recipient circuitry.
Given the above discussion, it will be appreciated that when considering any particular communication path within the data processing system, that communication path will interconnect initiator circuitry at one end with recipient circuitry at the other end, and the initiator circuitry can initiate transactions, with the recipient circuitry then handling each such transaction. For a communication path within the interconnect circuitry, the recipient circuitry will typically handle the transaction by performing the required routing operations to direct the relevant transfer(s) of the transaction between that communication path and the next communication path along the link between the master and the slave device. When considering the ultimate recipient slave device, the slave device will handle each transaction by performing the required read or write operations.
It is useful within data processing systems to be able to measure values of a predetermined property of the transactions handled by the data processing system. Further, it is useful to be able to measure the values of such a predetermined property at a variety of different locations with the system. For example, it may be desirable to measure the predetermined property at any one of the various communication paths discussed above. Such measurements can be useful in a variety of situations, for example when undertaking performance profiling in order to determine whether the data processing system is operating as expected. One example of a property of a transaction which may be useful to measure is latency. At any particular communication path, latency can be measured by observing the time between the initial request (typically the address transfer) issued by the initiator circuitry, and a time indicative of the end of the transaction, for example the timing of a predetermined response from the recipient circuitry. A measurement device could hence be arranged to snoop the various transfers occurring over a particular communication path in order to detect the start of a transaction and the corresponding end of a transaction, and thereby calculate the latency of the transaction.
However, many modern data processing systems use transaction protocols which allow multiple transactions to be pending at any point in time, and allow out of order responses to those transactions. In such systems, it is often the case that transaction identifiers (IDs) are used to enable the individual transfers making up a transaction to be identified, so that an address transfer at the start of a transaction can be matched up with the various data transfers of that transaction. In such situations, in order to measure latency of transactions in the manner described above, it would be necessary to perform full transaction tracking in respect of the communication path, which is very expensive in terms of both power and area. For example, such full transaction tracking could be achieved by providing a stack-based scheme, where each new transaction observed is pushed on to the stack along with an indication of a start time, and when each transaction end is observed, that transaction end is matched with the corresponding transaction start stored in the stack by matching of the transaction IDs, the relevant entry is removed from the stack, and a determination of the transaction latency is made for that transaction.
There are various problems with such an approach. Firstly, a determination needs to be made at design time as to how many pending transactions will need to be tracked, as this will determine the size of the stack provided for tracking the pending transactions. Further, such an approach is relatively complex in terms of the hardware required to support the full transaction tracking. In addition, the requirement for full tracking means that the tracking circuitry must be on all of the time, and cannot be switched on and off arbitrarily, since this could cause incorrect matching of transaction ends with transaction starts. For example, it is often the case that the transaction IDs used for transactions are not unique, and multiple pending transactions using the same ID can be present (it is typically the case that such pending transactions using the same ID have to complete in order). If tracking circuitry such as described above were turned on at some arbitrary point, it will be appreciated that the tracking circuitry would not operate reliably, and incorrect latency measurements could be taken.
Accordingly, it would be desirable to provide an improved technique for measuring values of a predetermined property of transactions, which is less complex and more flexible than the earlier described mechanism.